home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20000114-20000217
/
000053_news@columbia.edu _Mon Jan 17 20:55:56 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
8KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id UAA05215
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 17 Jan 2000 20:55:55 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id UAA03092
for kermit.misc@watsun.cc.columbia.edu; Mon, 17 Jan 2000 20:48:21 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Subject: Re: MS-DOS Kermit, more capabalities
Date: 18 Jan 2000 01:48:20 GMT
Organization: Columbia University
Message-ID: <860gp4$30h$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In article <OoOg4.6711$NU6.285660@tw12.nn.bcandid.com>,
<cangel@famvid.com> wrote:
: FD> If you want Zmodem software with Kermit scripting for DOS, you're
: FD> in the unenviable position of having to put it together yourself.
: FD> It's not Omen's job to give you Kermit scripting, and it's not our
: FD> job to give you Zmodem protocol.
:
: You keep saying this and yet zmodem found it's way into the WIN95 Kermit.
: Are you not aware that zmodem is in the WIN95 Kermit? If it doesn't
: belong in there someone should remove it.
We are very well aware that Zmodem is in Kermit 95. I put it there.
As I have stated repeatedly in this thread, the Zmodem support in
K95 is there because somebody donated it with the condition that it
only be used in Kermit 95.
: --8<--cut
:
: FD> There are real people at work here. For some of us, it is our job.
: FD> For others, all participation is voluntary, outside of their real
: FD> jobs. The demands on our time are greater than the time available.
: FD> We do our best to serve the largest number of people in the time we
: FD> have.
:
: Not quite sure what "real people" is supposed to mean in this context.
: It reads as though you left out the word "important".
:
: To say "We're really busy right now and are not able to get to anything
: new at this time." would be a nicer way to say the same thing IMO.
Frank has tried to be extremely polite and careful with his words.
Please do not add words to something Frank says because by doing so
you are reading what you want to hear and not what Frank is saying.
: FD> If you have bug reports, we welcome them. If you have questions of
: FD> reasonable scope, we try to answer them. If you have suggestions,
: FD> we'll listen to them, but we're not obligated to act on them. If we
: FD> have a hundred thousand users anxiously waiting for some particular
: FD> new feature in one of our programs, and one person looking for some
: FD> other feature, all else being equal, I think the course is clear.
:
: Could you give an example of this new feature you are all working on
: that 100,000 users are anxiously waiting for?
For a small idea of the work we have doing for the last three years
you may read
http://www.kermit-project.org/ckermit.html
for a description of C-Kermit 7.0 and the Internet Kermit Service.
This latest implementation of Kermit for Unix, VMS, VOS, ... and the
Kermit 95 for Windows 95/98/NT/2000 and OS/2 that will shortly follow
is what we have been working on.
This does not include the work we do as part of our involvement with
International Standards organizations, the Unicode Consortium, and
the Internet Engineering Task Force. Nor does it include the help
desk support we provide to end users via e-mail (9000 messages in the
last 12 months) plus telephone support. I think we have been rather
busy.
: --8<--cut
:
: FD> Nobody is going to wade through a long script hunting for where
: FD> the problem might be.
:
: "Nobody" is a bit general. I intend to try the script (it takes only
: 10 or 15 minutes) and see what happens.
A newsgroup is meant for user to user support in addition to developer
to user support. I look forward to your analysis of the problem and
hopefully a solution.
: --8<--cut
:
: FD> Nevertheless, we have been doing our best to show the BBS world how
: FD> they can improve the situation. Read, for example, the article on
: FD> MS-DOS Kermit and BBS's here:
:
: FD> http://www.columbia.edu/kermit/newsn6.html#bbs
:
: I have also mentioned the page on your website admitting that the
: misunderstanding about the 94 byte packets was caused by using it as
: the default setting for kermit for so many years. To be honest you
: are the people that caused the problem but won't admit it.
In what way are we responsible. The Kermit protocol has evolved from
1980 until the present. The first version supporting packets longer
than 94 bytes was released in May 1985. The reason that we have not
used greater than 94 bytes as the default packet length until Kermit 95
and C-Kermit 7.0 is that up until the present time we have been more
concerned with making sure that the transfer would work the first time
the user tried to transfer a file. Otherwise, users that need to
perform a transfer one and only one time would very frequently try
to transfer the file and have the transfer completely fail. They would
then be forced to learn a great deal more about Kermit than they would
want to. The fact that Kermit always worked when Zmodem often failed
is the primary reason that Kermit is often sought out.
We have made the change in C-Kermit 7.0 and Kermit 95 because the most
common use of Kermit for file transfers is now over TCP/IP connections
which are reliable. It is for this same reason that Kermit has evolved
to support streaming transfers. As long as TCP is ensuring error free
delivery of data there is no reason for Kermit to duplicate the effort.
: --8<--cut
:
: FD> MS-DOS Kermit and the environment it runs in have memory
: FD> limitations. Now, I'm all for the idea of keeping old equipment
: FD> alive and finding new uses for it, but when you consider that you
: FD> can buy an Internet ready PC with 32 or 64MB of memory today for a
: FD> fraction of the cost of the original IBM PC, maybe it's time to
: FD> look at how much your time is worth.
:
: There are many people who restore old automobiles, others restore old
: furniture. Do you think they should buy only `new'?
:
: For some this is a hobby and doing it with the original equipment or
: close to the original is a challenge. It's not always about money.
:
: Any fool can buy his way onto the Internet.
It may not be about money, but it is about time. What you are requesting
is that either Professor Doupnik or one of the paid members of the
Kermit Project take our time to develop and implement a Zmodem
implementation for MS-DOS Kermit. This is not a trivial one hour
job. If it were it might have been done years ago.
It is also a memory trade off. As you have seen from threads this
week there are concerns about memory space and scripts. Adding
45K of code to MS-DOS Kermit it would significantly reduce the
size of the scripts that might be implemented.
: --8<--cut
:
: FD> Here are a couple observations that might be helpful:
:
: FD> 2. The command to use for ASCII uploads is TRANSMIT. If you use
: FD> that instead of OPEN READ, READ, ..., CLOSE READ, you won't
: FD> experience any interference with the data.
:
: I've used the TRANSMIT a few times. The entire screen goes haywire and
: looks like a runaway ASM program (core dump?) but when it finally stops
: the data has been transmitted. A bit unnevering to watch if you've had
: many ASM programs try trashing your hard drive on you.
:
: It appears to be functional but could use a better display format that
: doesn't scare the heck out of you when you do use it IMO.
Turn off echoing if you do not desire it.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org